在上篇中我们对AutoSar OS有了一定的了解，接下来让我们更进一步的了解OS的进阶知识。
AUTOSAR OS是基于优先级进行任务调度，所以每个任务必定有一个优先级，而每个任务都是根据其自身特点来定义一个优先级且需要配置其可抢占属性。
可抢占属性可分为不可抢占与全抢占，这里所说的抢占指的是内核抢占。AUTOSAR OS可根据各个任务的可抢占属性配置，来提供不同的调度策略，调度策略可分为以下三种：
完全抢占式：OS所有任务均是可抢占类型；
非抢占式：OS中所有任务均是不可抢占的；
混合抢占式：OS部分任务是可抢占类型，部分任务是不可抢占类型；
通过例子更好的了解三种调度策略的使用，在例子中我们设定TaskA为扩展任务，TaskB与TaskC为基本任务，优先级TaskA > TaskB > TaskC。
当前运行的任务可在任何时刻被高优先级任务打断而被迫释放处理器控制权，具备最高优先级的任务从就绪状态转入运行状态，而当前任务被抢占从而进入就绪状态，同时保留现场环境，待下次运行时恢复。
当前TaskC处于运行状态，当激活TaskB进入到就绪状态时，由于TaskB优先级高于TaskC，所以TaskC被迫释放处理器控制权，调度器开始调度TaskB从就绪状态变为运行状态，直到TaskB运行完成之后，再调度TaskC继续运行。
当前TaskC处于运行状态，激活TaskA与TaskB分别进入就绪状态，由于TaskA优先级高于TaskB，所以TaskA抢占内核运行， 但是由于Resource1仍被TaskC暂用，而TaskA（扩展任务）无法访问到共享资源Resource1，则被迫进入到等待状态，TaskB开始运行。TaskB运行结束后挂起之后则重新运行TaskC，TaskC运行结束后释放Resource1，进入TaskA得以由等待状态转入运行状态。
按照正常理解高优先级任务应该比低优先级任务更快触发，但在上述第二个例子中却没有按照这样的流程进行，该现象也被称为优先级反转现象。即若TaskC运行过程中占用共享资源Resource1，此时即使存在需占用共享资源的高优先级任务TaskA被激活，也必须保证TaskC运行结束，才能执行TaskA，也就意味着在重要代码执行之前，应采用资源保护机制，以免被高优先级的任务打断。
当前运行状态的任务在任何时刻都不会其他高优先级任务所抢占，任务的切换只会发生在任务完时。 非抢占式调度策略的问题在于任务执行时间不确定，系统调度实时性较差。如下图8所示为非抢占式调度策略，可见即使高优先级任务 TaskB被激活切换至就绪状态，也必须等到TaskC执行结束之后才能够被调度。
OS的调度策略就取决于当前任务的可抢占属性，如果为非抢占，则执行非抢占式调度策略，如果为抢占式则执行完全抢占式调度策略。
在多任务操作系统中，资源管理是协调具有不同优先级的多个任务或中断对共享资源（如内存或硬件）并发访问的关键。为了确保系统的稳定性和高效性，AUTOSAR OS采用了优先级天花板模式（Priority Ceiling Protocol）来避免任务优先级反转和死锁问题的发生。
优先级天花板模式的核心思想是为每个资源设置一个上限优先级。这个上限优先级必须高于所有访问该资源的任务和中断的优先级，但应低于不访问该资源的任务的最低优先级。通过这种方式，可以确保高优先级的任务不会因为等待低优先级任务释放资源而被阻塞，从而避免了优先级反转和死锁问题。
为了保护共享资源，AUTOSAR OS引入了自旋锁（Spin Lock）机制。自旋锁主要用于多核操作系统中解决资源互斥的问题。当内核控制必须访问共享数据结构或进入临界区时，如果自旋锁已经被别的执行单元保持，调用者会一直循环检查该自旋锁是否已被释放。这种机制通过忙等待（busy-waiting）来确保对共享资源的互斥访问。
获取自旋锁：当一个执行单元（如任务或中断服务程序）需要访问共享资源时，它会尝试获取自旋锁。如果自旋锁空闲，则该执行单元可以立即获取锁并访问资源。如果自旋锁已被其他执行单元占用，调用者会进入一个循环，不断检查锁的状态，直到锁被释放。
释放自旋锁：当执行单元完成对共享资源的访问后，它会释放自旋锁，使其他等待的执行单元能够继续执行。
如上篇文章得知AUTOSAR OS来源于OSEK OS，但随着汽车电子信息安全，功能安全等需求的不断提出，传统的OSEK OS已无法满足当前的需求，因此AUTOSAR组织在OSEK OS的基础上为不同的用户提供四类不同功能安全的OS可裁剪类型，分别为SC1-SC4，下图中清晰的展现了SC1-SC4间联系：
SC1: OSEK OS + Schedule Table；
SC2: OSEK OS + Schedule Table + Timing Protection;
SC3: OSEK OS + Schedule Table + Memory Protection;
SC4: OSEK OS + Schedule Table + Timing Protection + Memory Protection；
AUTOSAR OS作为一实时操作系统，需要在预定的时间内完成特定的任务，但有时由于某些原因导致超时错误，OS必须采用有效的方式来预防超时任务的发生，而这类措施则称为时间保护。
一种较为常见的时间保护就是Deadline Monitoring。当OS检测到某一任务的运行时间超过其截止时间时，则会调用相应的Hook函数向系统报错，但AUTOSAR OS并不是通过监控截止时间方式来实现时间保护，因为针对截止时间的保护并不能准确识别出当前错误的原因。具体解释如下：
现象： 任务A的运行时间超过其截止时间时，任务A本身可能并没有出错；
过程： 在执行任务A之前的任务B频繁的抢占或者过长的阻塞资源的访问；
原因： 正由于任务B的上述行为，进而导致任务A执行超时，从而直观的认为任务A发生错误便停止任务A，反而让任务A超时的任务B没有接受任何处理，这就不合情理，也起不到对OS中各任务的时间保护。
为了进一步加强大家对上述简单的监控截止时间造成运行错误的理解，假设存在一个操作系统中存在下列任务A，B，C，并明确各自任务的优先级，执行时间，Deadline 如下图中所示
假设所有任务在0时刻均处于就绪状态，期望运行的任务执行时序如下图所示。具体的任务执行时序如下所述：
由于任务A优先级最高，因此任务A先执行；
1个Tick（时间戳）之后任务B开始执行，3个Tick之后任务C执行；
当任务C执行1个Tick后被任务A打断，任务A执行完毕后，任务C继续运行；
到第10个Tick任务C执行完毕，周而复始，整个过程并未出现超时现象，并且仍有一个Tick的空闲状态；
接下来，如果发生如下图所示的异常状况，任务A和任务B抢占共享资源：
任务A的第二个周期与任务B的第一个周期都出现运行时间过长的现象，但并没有超过其截止时间。
任务B在第二个周期提前进入运行状态，但也未超过其截止时间；
任务C按照正确的方式运行，但由于任务A与任务B的出错导致任务C运行超时，则发生超时错误；
若此时采用简单的超时监控机制只能监控到任务C超时，这时操作系统调用Hook函数，由于出错原因并未被检测到，从而操作系统采取的措施将无法有效解决错误。
从上述例子分析可以得出任务或者中断能否满足其截止时间需取决于以下三大基本要素：
静态任务或者中断的执行时间上限；
被低优先级任务锁住共享资源或屏蔽中断所引起的阻塞时间；
任务或者中断之间的间隔执行时间；
针对上述三大基本要素，AUTOSAR OS采取了下列三种时间保护机制：
AUTOSAR OS为任务或者二类中断服务设定了运行时间上限；
AUTOSAR OS设定了共享资源被任务或者二类中断锁定的时间上限，设定了OS中断被任务或者二类中断中断挂起的时间上限，设定了所有中断被任务或者二类中断挂起或者屏蔽的时间上限；
AUTOSAR OS设定了任务或者二类中断执行间隔的时间下限；
注意AUTOSAR OS时间保护存在一些基本特性：
时间保护仅仅用于任务或者二类中断，对于一类中断不起作用；
在OS未开启之前，时间保护将不起作用；
对于Trusted OS Application, OS应当有能力提供一种基于任务或者二类中断的时间保护；
对于Non-Trusted OS Application，OS必须提供为这个非信任的OS Application中的每一个任务或者二类中断提供时间保护；
AUTOSAR OS的内存保护需要特定的硬件支持，即处理器应该存在MPU单元(Memory Protection Unit)，内存保护可以有效防止出错的应用模块影响到其他模块，降低系统完全瘫痪的风险，因此，AUTOSAR OS提供以下三种形式的保护：
栈保护：即每一个OS Application和其中的OS Object都有各自的私有栈，不同的OS Object无需存在共享栈。栈保护能够更为快速的检测出栈溢出，同时栈保护也是划分OS Application的一种方式和依据。
数据保护：每一个OS Application和其中的Objects都具备各自私有数据，同时OS Application的私有数据区就是从属于该OS Application的Objects的共享数据区；
代码保护：代码区既可以被私有，也可以被共享，在没有代码保护的前提下，错误代码的执行会导致内存，时间和服务上的出错。
服务热线：
0551-65691812
客户留言
0551-65691812
